Secure identity propagation in a cloud-based computing environment

ABSTRACT

The present disclosure describes methods, systems, and computer program products for providing secure identity propagation in a cloud-based computing environment. One computer-implemented method includes receiving, from a user, a first security response message, transmitting, to the user in response to receiving the first security response message, a second security response message, wherein the second security response message comprises a Token Granting Token (TGT), receiving, from a cloud application, a Service Token (ST) request, wherein the ST request comprises the TGT, verifying the ST request based on the TGT, generating, in response to the verifying, a ST, wherein the ST is used to validate an access request to access a backend system, and transmitting the ST to the cloud application.

BACKGROUND

Organizations today use cloud-based services to run their enterpriseapplications. In many cases, those applications require the integrationwith internal backend systems that run in the organization's datacenter, such as an Enterprise Resource Planning (ERP) system. In such ahybrid cloud scenario, the cloud application typically requires the userto authenticate with their credentials, such as a username and password,biometric information, and/or other credentials. Verification of theuser's credentials is usually delegated to a trusted identity provider(IDP) that manages the user's account, e.g., a corporate IDP like theorganization's user directory. A common and standardized protocol fordelegating the authentication to the IDP is the Security AssertionMarkup Language (SAML) 2.0.

SUMMARY

The present disclosure relates to computer-implemented methods,computer-readable media, and computer systems for secure identitypropagation in a cloud-based computing environment. Onecomputer-implemented method includes receiving, from a user, a firstsecurity response message, transmitting, to the user in response toreceiving the first security response message, a second securityresponse message, wherein the second security response message comprisesa Token Granting Token (TGT), receiving, from a cloud application, aService Token (ST) request, wherein the ST request comprises the TGT,verifying the ST request based on the TGT, generating, in response tothe verifying, a ST, wherein the ST is used to validate an accessrequest to access a backend system, and transmitting the ST to the cloudapplication.

Other implementations of this aspect include corresponding computersystems, apparatuses, and computer programs recorded on one or morecomputer storage devices, each configured to perform the actions of themethods. A system of one or more computers can be configured to performparticular operations or actions by virtue of having software, firmware,hardware, or a combination of software, firmware, or hardware installedon the system that in operation causes the system to perform theactions. One or more computer programs can be configured to performparticular operations or actions by virtue of including instructionsthat, when executed by data processing apparatus, cause the apparatus toperform the actions.

The foregoing and other implementations can each optionally include oneor more of the following features, alone or in combination:

A first aspect, combinable with the general implementation, wherein thefirst security response message is generated by an Identity Provider(IDP).

A second aspect, combinable with any of the previous aspects, whereinthe TGT comprises a TGT digital signature, and wherein the verificationof the ST request is based on the TGT digital signature.

A third aspect, combinable with any of the previous aspects, wherein theTGT further comprises a lifetime parameter, and wherein the verificationis further based on the lifetime parameter.

A fourth aspect, combinable with any of the previous aspects, whereinthe ST comprises a ST digital signature that is used in validating theaccess request.

A fifth aspect, combinable with any of the previous aspects, wherein theST further comprises a lifetime parameter, and wherein the lifetimeparameter is used in the validation.

A sixth aspect, combinable with any of the previous aspects, wherein thesecond security response message is transmitted on a cloud platform thathosts the cloud application.

A seventh aspect, combinable with any of the previous aspects, whereinthe first and the second security response messages are formattedaccording to the Security Assertion Markup Language (SAML) responsemessage.

The subject matter described in this specification can be implemented inparticular implementations so as to realize one or more of the followingadvantages. First, propagating a secure identity according to themethods and systems described herein includes a trusted Secure TokenService (STS) that generates and verifies STs and TGTs. This trusted STSmay ensure that the STs and TGTs are issued for the IDP-authenticateduser in the cloud application, and thereby shields the responsibilitiesof generating secure tokens away from the cloud applications. Second,this approach reduces restrictions by a cloud provider on the cloudapplication in order to make the cloud application a more trustworthysystem for generating security tokens. Therefore, this approach enhancesthe usability of the application and the developer's flexibility indeveloping the application. Third, the SAML standard originally designedfor Single Sign-On (SSO) scenarios may be extended to securely propagateauthenticated user identity from the cloud application to another system(e.g., a backend system on the customer's internal network). Thisapproach extends the use and functionality of the SAML protocols thatremains compatible with the SAML standards, e.g., the SAML 2.0 standard.

The details of one or more implementations of the subject matter of thisspecification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a high-level architecture block diagram illustrating a secureidentity propagation system according to an implementation.

FIG. 2 is a flow diagram of a method illustrating a Token Granting Token(TGT) issuing process according to an implementation.

FIG. 3 is a flow diagram of a method illustrating a Service Token (ST)issuing and application process according to an implementation.

FIG. 4 is a block diagram of an exemplary computer used in the secureidentity propagation system according to an implementation.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

The following detailed description is presented to enable any personskilled in the art to make, use, and/or practice the disclosed subjectmatter, and is provided in the context of one or more particularimplementations. Various modifications to the disclosed implementationswill be readily apparent to those skilled in the art, and the generalprinciples defined herein may be applied to other implementations andapplications without departing from the scope of the disclosure. Thus,the present disclosure is not intended to be limited to the describedand/or illustrated implementations, but is to be accorded the widestscope consistent with the principles and features disclosed herein.

Organizations today use cloud-based services to run their enterpriseapplications. In many cases, those applications require the integrationwith internal backend systems that run in the organization's datacenter, such as an Enterprise Resource Planning (ERP) system. In such ahybrid cloud scenario, the cloud application typically requires the userto authenticate with their secret credentials, such as a username andpassword. Verification of the user's credentials is usually delegated toa trusted identity provider (IDP) that manages the user's account, e.g.,a corporate IDP like the organization's user directory. A common andstandardized protocol for delegating the authentication to the IDP isthe Security Assertion Markup Language (SAML) 2.0.

In general, access to the backend system requires an authenticated user.To avoid asking the user again for their backend credentials, the cloudapplication may propagate the already authenticated user to the backendsystem. A common technique to propagate the user is a security tokenthat represents the user's identity. However, according to SAMLstandards, a cloud application may not reuse an already consumedsecurity token. In other words, although the cloud application receivedsuch a security token, e.g., the SAML Assertion, from the IDP in thecourse of a successful SAML-based login, the cloud application may notpropagate the security token to the backend system.

Therefore, a new security token may be generated and issued for the userby the cloud application. The new security token may be signed by thecloud application. However, the cloud application is an unsuitable placefor performing such a highly sensitive security task. For example, amalicious application may be able to access the local file system oropen network connections to read the confidential key that is used togenerate the token signature. The malicious application could thenemulate an arbitrary user independent of whether this user is actuallyauthenticated.

Note that the described secure identity propagation system should notlimit the described subject matter to the illustrated examples. In otherpossible implementations, there can be a specific system for thegeneration, issuance, and application of the TGT and the ST.

FIG. 1 is a high-level architecture block diagram illustrating a secureidentity propagation system 100 for implementing a secure identitypropagation process according to an implementation. At a high level, theillustrated secure identity propagation system 100 includes or is madeup of one or more communicably coupled computers (e.g., the computerdescribed in FIG. 4) that communicate across a network 130 (note thatalthough only three network 130 connections have been labeled in FIG. 1,one or more of the other indicated connections between components canalso be considered part of network 130). In some implementations, thesecure identity propagation system 100 or portions of the secureidentity propagation system 100 can operate within acloud-computing-based environment. The illustrated secure identitypropagation system 100 includes a user 102 that is communicably coupledwith an IDP 104 and a cloud 110 over the network 130. The cloud 110,which includes a cloud application 112 and a cloud STS 114, is furthercommunicably coupled with a backend system 120. The describedillustration is only one possible implementation of the describedsubject matter and is not intended to limit the disclosure to the singledescribed implementation. Those of ordinary skill will appreciate thefact that the described components can be connected, combined, and usedin alternative ways consistent with this disclosure.

The user 102 is any person, device, or program that intends to accessthe backend system 120 through the cloud 110. The user 102 can interactwith the cloud 110 and the IDP 104 through a web browser, a mobileclient, or any other client software that is located at a client site.In some cases, the user 102 is an authorized user to access the backendsystem 120. For example, the user 102 can be an employee or anauthorized customer of a corporation that controls the backend system120.

The backend system 120 represents an application, set of applications,software, software modules, and/or combination of software and hardwarethat provides backend services to the user 102 through the cloud 110. Insome cases, the backend system 120 can provide enterprise services tothe user 102. For example, the backend system 120 can part of theinternal network of a corporation. The user 102 can be an employee or acustomer of the corporation and can access the backend system 120 toperform enterprise operations. For example, the backend system 120 canbe internal to a corporation's data center, such as an EnterpriseResource Planning (ERP) system.

In some cases, the backend system 120 can authenticate the user 102before providing user access to the enterprise service. Before thebackend system can authorize a user, it must authenticate the user whichis possible base on the information in a Security Token (ST). In theseor other cases, the backend system 120 can perform the authenticationbased on the ST and the ST can be signed by an STS. FIGS. 2-3 andassociated descriptions provide detailed descriptions of theseprocesses.

The IDP 104 represents an application, set of applications, software,software modules, or combination of software and hardware that acts asan IDP. In some implementations, the IDP 104 follows a common andstandardized protocol, e.g., the Security Assertion Markup Language(SAML) 2.0, for delegating the authentication to the IDP 104. The IDP104 manages users' account information and can verify user 102'scredentials. For example, the IDP 104 can be a corporate IDP like theorganization's user directory. The IDP 104 can store secret userinformation such as username, password, and answers to securityquestions. When the IDP 104 receives a security request, the IDP 104 canverify the user 102 by comparing the user credentials entered by theuser 102 with the stored account information of the user 102. Upon thesuccessful verification of the user 102, the IDP 104 can send a securityresponse message which can be used to generate a Token Granting Token(TGT), used to generate an ST. FIGS. 2-3 and associated descriptionsprovide detailed descriptions of these processes.

The cloud 110 can be any cloud platform that provides the user 102access to the cloud application 112. Examples of the cloud 110 caninclude HANA cloud platform, Microsoft Azure cloud platform, and/orGoogle Application Engine. As illustrated, the cloud 110 includes acloud application 112 and a cloud Secure Token Service (STS) 114.

The cloud application 112 represents an application, set ofapplications, software, software modules, or combination of software andhardware that provides enterprise services to the user 102. For example,the cloud application 112 can execute work flow, enable collaborationsbetween users, or retrieve enterprise data. In some cases, the cloudapplication 112 can access the backend system 120 to perform theenterprise services. In such a case, the cloud application 112 can makea backend call to request access to the backend system 120 on behalf ofthe user 102. In some implementations, the backend call can include a STthat is digitally signed by the cloud STS 114. The backend system 120can verify the user 102 based on the ST and grant access.

The cloud 110 also includes the cloud STS 114. The cloud STS 114represents an application, set of applications, software, softwaremodules, and/or combination of software and hardware that verifies theuser 102 and issues the TGT and the ST for the user 102. In someimplementations, the cloud STS can follow a common and standardizedprotocol, e.g., the Security Assertion Markup Language (SAML) 2.0, forproviding security verifications. The cloud STS 114 maintains a trustedrelationship with the IDP 104, and therefore can authenticate a firstsecurity response message that is generated by the IDP 104, whichindicates that the user 102 has been verified by the IDP 104. Uponauthentication, the cloud STS 114 can generate a second securityresponse message based on the first security response message. The cloudSTS 114 can also include a TGT in the second security response message.The cloud STS 114 also maintains a trusted relationship with the cloudapplication 112. Therefore, the cloud STS 114 can authenticate the STrequest from the cloud application 112. Upon authentication, the cloudSTS 114 can generate and send a ST to the cloud application 112.Furthermore, the cloud STS 114 maintains a trusted relationship with thebackend system 120. Therefore, the backend system 120 can authenticatethe backend call from the cloud application 112 based on the STgenerated by the cloud STS 114. FIGS. 2-3 and associated descriptionsprovide detailed descriptions of these processes.

Maintaining the cloud STS 114 as an entity that is separated from thecloud application 112 can provide one or more advantages. For example,this approach shields the generations and verifications of securitytokens away from the cloud application 112. This approach not onlyreduces the complexities of cloud application 112, but also mitigatessecurity concerns for malicious cloud applications. In addition, thecloud STS 114 can be a security application that is maintained by thecloud provider of the cloud 110, which can provide additional securitysafeguard for the cloud STS 114. In the illustrated example, the cloudSTS 114 is located on the same cloud that hosts the cloud application112. This approach can reduce the communication latency between thecloud STS 114 and the cloud application 112 and improve the efficiencyof the signal exchanges. In some implementations, the cloud STS 114 canbe located at/associated with a different entity from the cloud 110.

The network 130 facilitates wireless or wireline communications betweenthe components of the example system 100 (e.g., between the user 102 andthe IDP 104, the cloud STS 114, and the cloud application 112), as wellas with any other local or remote computer, such as additional clients,servers, or other devices communicably coupled to network 130, includingthose not illustrated in FIG. 1. In the illustrated environment, thenetwork 130 is depicted as a single network, but can be comprised ofmore than one network without departing from the scope of thisdisclosure, so long as at least a portion of the network 130 canfacilitate communications between senders and recipients. In someinstances, one or more of the illustrated components can be includedwithin network 130 as one or more cloud-based services or operations.

While portions of the software elements illustrated in FIG. 1 are shownas individual modules that implement the various features andfunctionality through various objects, methods, or other processes, thesoftware can instead include a number of sub-modules, third-partyservices, components, libraries, and such, as appropriate. Conversely,the features and functionality of various components can be combinedinto single components as appropriate.

FIG. 2 is a flow diagram of a method 200 illustrating a Token GrantingToken (TGT) issuing process according to an implementation. For clarityof presentation, the description that follows generally describes method200 in the context of FIGS. 1 and 3-4. However, it will be understoodthat method 200 may be performed, for example, by any other suitablesystem, environment, software, and hardware, or a combination ofsystems, environments, software, and hardware as appropriate. In someimplementations, various steps of method 200 can be run in parallel, incombination, in loops, and/or in any order.

At 202, the user 102 accesses a protected resource in the cloudapplication 112. This step initiates an authentication process by thecloud application 112 to authenticate the user.

At 204, the cloud application 112 sends a security request message torequest authentication information of the user 102. In the illustratedexample, the cloud application 112 sends a SAML Request message to anIDP 104. In some implementations, the SAML request message is routedthrough a web browser at the user 102 to the IDP 104. The SAML requestmessage can include an STS URL as the Assertion Consumer Service (ACS)endpoint. The following represents an example SAML request message:

<AuthnRequest ...AssertionConsumerServiceURL=“https://sts.hana.ondemand.com/saml2/acs”><ns2:Issuer>cloudapp.acme.com</ns2:Issuer> <ds:Signaturexmlns:ds=“http://www.w3.org/2000/09/xmldsig#”> ... </ds:Signature></AuthnRequest>.

At 206, the IDP 104 authenticates the user 102. In some implementations,the IDP 104 authenticates the user 102 by verification of thecredentials of the user 102 with the stored credential information. Forexample, the IDP 104 can ask the user 102 to enter a username andpassword to authenticate the user 102.

At 208, the IDP 104 sends a first security response message to the user102 to indicate a successful authentication. In some implementations,the first security response message can be SAML Response_(IDP) message.The SAML Response_(IDP) message can include a FORM element in a HTMLpage. The FORM element can include a hidden field according to the SAML2.0 Web Single Sign-On (SSO) profile. The HTML page can include scriptcode that will automatically post the FORM to the ACS URL specified at204. The SAML Response_(IDP) message can include a SAML Assertion_(IDP).The following represents an example SAML Response_(IDP) message,including the SAML Assertion_(IDP).

Response xmlns=“urn:oasis:names:tc:SAML:2.0:protocol” ...><ns2:Issuer>idp.acme.com</ns2:Issuer> <Status> <StatusCodeValue=“urn:oasis:names:tc:SAML:2.0:status:Success” /> (SAMLAssertion_(IDP)) </Status> <Assertionxmlns=“urn:oasis:names:tc:SAML:2.0:assertion” ...><Issuer>idp.acme.com</Issuer> <ds:Signaturexmlns:ds=“http://www.w3.org/2000/09/xmldsig#”> ... </ds:Signature><Subject> <NameIDFormat=“urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”>john.doe</NameID><SubjectConfirmation Method=“urn:oasis:names:tc:SAML:2.0:cm:bearer”><SubjectConfirmationData InResponseTo=“Sd9530e5a-be1-45c3-b873”NotOnOrAfter=“2014-08-27T08:02:15.692Z”Recipient=“https://sts.hana.ondemand.com/saml2/acs” /></SubjectConfirmation> </Subject> <Conditions ...> <AudienceRestriction><Audience>cloudappacme.hana.ondemand.com</Audience></AudienceRestriction> </Conditions> <AuthnStatement ...> ...</AuthnStatement> <AttributeStatement> <Attribute Name=“mail”><AttributeValue ...>john.doe@acme.com</AttributeValue> </Attribute><Attribute Name=“first_name”> <AttributeValue ...>John</AttributeValue></Attribute> <Attribute Name=“last_name”> <AttributeValue...>Doe</AttributeValue> </Attribute> </AttributeStatement> </Assertion></Response>

At 210, the user 102 sends the first security response message to thecloud STS 114. In some implementations, the first security responsemessage is a SAML Response_(IDP) message. The user 102 can post the SAMLResponse_(IDP), via a web browser, to the cloud STS 114 by using the STSACS endpoint specified at 204.

At 212, the cloud STS 114 generates a second security response message.In the illustrated example, the cloud STS 114 uses the informationobtained from the first security response message, e.g., the SAMLResponse_(IDP) message, received at 210 to generate the second securityresponse message. For example, the cloud STS 114 can use SAMLAssertion_(IDP) in the SAML Response_(IDP) message to generate a SAMLAssertion_(STS). The cloud STS 114 can include the SAML Assertion_(STS)in the second security response message, e.g., a SAML Response_(STS)message. The cloud STS 114 can set the Recipient attribute to theidentifier of the cloud application 112, which can be determined basedon the SAML Response_(IDP) Audience element value, or from a domaincookie set by the cloud application 112 with the security requestmessage in 204. If a domain cookie is used, the cloud STS 114 and cloudapplication 112 can be in the same DNS domain. The following representsan example SAML Response_(STS) message, including the SAMLAssertion_(STS).

<Response xmlns=“urn:oasis:names:tc:SAML:2.0:protocol” ...><ns2:Issuer>idp.acme.com</ns2:Issuer> <Status> <StatusCodeValue=“urn:oasis:names:tc:SAML:2.0:status:Success” /> (SAMLAssertion_(STS)) </Status> <Assertionxmlns=“urn:oasis:names:tc:SAML:2.0:assertion” ...><Issuer>idp.acme.com</Issuer> <ds:Signaturexmlns:ds=“http://www.w3.org/2000/09/xmldsig#”> ... </ds:Signature><Subject> <NameIDFormat=“urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”>john.doe</NameID><SubjectConfirmation Method=“urn:oasis:names:tc:SAML:2.0:cm:bearer”><SubjectConfirmationData InResponseTo=“Sd9530e5a-be18-45c3-b873”NotOnOrAfter=“2014-08-27T08:02:15.692Z”Recipient=“https://sts.hana.ondemand.com/saml2/acs” /></SubjectConfirmation> </Subject> <Conditions ...> <AudienceRestriction><Audience>cloudappacme.hana.ondemand.com</Audience></AudienceRestriction> </Conditions> <AuthnStatement ...> ...</AuthnStatement> <AttributeStatement> <Attribute Name=“mail”><Attribute Value ...>john.doe@acme.com</AttributeValue> </Attribute><Attribute Name=“first_name”> <AttributeValue ...> John</AttributeValue></Attribute> <Attribute Name=“last_name”> <AttributeValue...>Doe</AttributeValue> </Attribute> </AttributeStatement> </Assertion></Response>

The SAML Assertion_(STS) can include an additional security tokengenerated by the cloud STS 114. In the illustrated example, theadditional security token is a Token Granting Token (TGT). In someimplementations, the TGT can be a SAML Assertion Attribute. The TGT caninclude additional security information. The additional information inthe TGT can include a unique name of the TGT issuer, e.g., the cloud STS114. The additional security information in the TGT can also include thesubject name of the IDP-authenticated user 102. The cloud STS 114 canset the subject name to the value of the NameID element in the SAMLResponse_(IDP). In some cases, the additional security information inthe TGT can also include other user identity information provided by theIDP in the SAML Assertion_(STS), such as the user's first name, theuser's last name, the user's department, the user's organization, and/orother information about the user 102. The additional securityinformation in the TGT can also include a unique identifier of the TGTand a unique identifier of the recipient that the TGT is intended for,e.g., the cloud application 112. The cloud STS 114 can set the uniqueidentifier of the recipient to the value of the Audience element in theSAML Response_(IDP).

In some implementations, the additional security information in the TGTcan include a lifetime value for the TGT. The association of the TGT tothe IDP-authenticated user 102 can persist until the lifetime indicatedby the lifetime value expires. In some cases, a malicious cloudapplication may cache the TGT for users who successfully authenticatedat the IDP 104. The malicious application could use the cached TGT tomake authorized calls to the backend system 120 on behalf of theseusers. Setting a lifetime for the TGT may mitigate this risk.

The additional security information in the TGT can also include a STSdigital signature. The STS digital signature is generated by the cloudSTS 114 and covers the additional security information in the TGT. Thefollowing represents an example TGT in the JSON Web Token (JWT) Formatthat can be processed according to the JSON Web Signature (JWS)specification:

{ “iss”: “sts.hana.ondemand.com”, “sub”: “john.doe”,“jti”:“Sd9530e5a-be18-45c3-b873-34c8d10cdb3f, “aud”:“https://cloudappacme.hana.ondemand.com”, “exp”: “1219831243” }

At 214, the cloud STS 114 sends the second security response message tothe user 102. For example, the cloud STS 114 can send a HTML page with aFORM element that contains a hidden field with the SAML Response_(STS)message according to the SAML 2.0 Web SSO profile. The HTML page caninclude script code that will automatically post the FORM to the ACS URLof the cloud application 112. Similar to how the Recipient attribute isset in 212, the ACS URL of the FORM element can be determined by theSAML Response_(IDP) Audience element or a domain cookie.

At 216, the user 102 sends the second security response message to thecloud application 112. For example, the user 102's Web Browser can postthe SAML Response_(STS) to the cloud application 112's ACS endpoint. Thecloud application 112 can log in the user 102 and create a new usersession. The user principal (object) of this session will be populatedwith the information found in the SAML Assertion_(STS) of the SAMLResponse_(STS). The TGT from the SAML Attribute “TokenGrantingToken” inthe SAML Assertion_(STS) can be set as a session attribute to make itavailable for the backend system call during the ST issuing andapplication process described in FIG. 3 and associated descriptions.

In some implementations, the messages described in FIG. 2 can betransmitted over an encrypted channel. This approach can mitigate therisk of known network attacks such as replay attack, sniffing, orsimilar man-in-the-middle attacks.

FIG. 3 is a flow diagram of method 300 illustrating a Service Token (ST)issuing and application process according to an implementation. Forclarity of presentation, the description that follows generallydescribes method 300 in the context of FIGS. 1-2 and 4. However, it willbe understood that method 300 may be performed, for example, by anyother suitable system, environment, software, and hardware, or acombination of systems, environments, software, and hardware asappropriate. In some implementations, various steps of method 300 can berun in parallel, in combination, in loops, and/or in any order.

At 302, the cloud application 112 sends a Service Token (ST) request tothe cloud STS 114. The ST is used to authorize a backend call to thebackend system 120 for the user 102. In the illustrated example, the TGTobtained by the cloud application 112 at 216 in FIG. 2 can be used torequest the ST from the cloud STS 114. The TGT, however, is not useddirectly as a service token to authorize the backend call. The STrequest can use an internal format. The ST request can also followexisting standards for interacting with an STS, such as the WS-Trustprotocol. The ST request can indicate the target (e.g., the backendsystem 120) where the ST will be used. From 302, method 300 proceeds to304.

At 304, the cloud STS 114 verifies the TGT received in the ST request byvalidating the STS digital signature included in the TGT. In someimplementations, the cloud STS 114 can keep an audit log record of theTGT issued in the TGT issuing process illustrated in FIG. 2. Further,the cloud STS 114 can maintain a list of targets that the cloudapplication 112 can request access to. The cloud STS can deny a STrequest from the cloud application 112 if the target backend system isnot registered for the cloud application 112.

The cloud STS 114 can consult with the audit log record to verify theTGT. In some cases, the TGT includes a lifetime value. In such a case,the cloud STS 114 can further verify whether the lifetime of the TGT hasexpired based on the lifetime value. If the STS digital signature isvalid and, in the case that the TGT includes a lifetime value, thelifetime of TGT has not expired, the TGT is verified.

Upon successful verification, the STS can generate a Service Token (ST).The ST can include additional ST information. The additional STinformation can include a unique name of the ST issuer, i.e., the cloudSTS 114. The additional ST information can also include the subject nameof the authenticated user associated with the TGT used to request theST. This subject name can be the same as the subject name of the TGT. Insome cases, the additional ST information can also include other useridentity information provided by the TGT, such as the user's first name,last name, department, organization, and/or other additional STinformation. The additional ST information can further include a uniqueidentifier of the ST and a unique identifier of the intermediaterecipient that the ST is intended for, i.e., the cloud application 112.The additional ST information can include a unique identifier of theultimate target the ST is consumed for propagating the user's identity,i.e., the backend system 120.

In some implementations, the additional ST information can include a STlifetime value. The association of the ST to the IDP-authenticated user102 can persist until the ST lifetime indicated by the ST lifetime valueexpires. In some cases, a malicious cloud application can cache the STfor users who successfully authenticated at the IDP 104 and the cloudSTS 114. The malicious application could use the cached ST to makeauthorized calls to the backend system 120 on behalf of these users.Setting a lifetime for the ST can mitigate this risk. In someimplementations, the TGT can have a longer lifetime than the ST, toavoid repeating the TGT issuing process illustrated in FIG. 2. The STtoken can have a short lifetime because it is likely to be usedimmediately after requesting it from the cloud STS 114.

Furthermore, the additional information can include a ST digitalsignature. The ST digital signature is generated by the cloud STS 112 tocover the additional ST information included in the ST. The followingrepresents an example ST in the JSON Web Token (JWT) Format that can beprocessed according to the JWS specification (e.g., to add a signature).In the example, a private (unregistered) claim name (e.g., in the formof “http://hana.ondemand.com/target”) is used to specify the intendedtarget where the ST will ultimately be sent to for propagating the user:

{ “iss”: “sts.hana.ondemand.com”, “sub”: “john.doe”,“jti”:“as234e5a-34gf-aske-bgen-9kldja08923f, “aud”:“https://cloudappacme.hana.ondemand.com”, “exp”: “2139081231”,“http://hana.ondemand.com/target”: “https://erp.acme.com” }From 304, method 300 proceeds to 306.

At 306, the cloud STS 114 sends a ST response to the cloud application112. The ST response includes the ST generated at 304. This ST messagecan have an internal format or can follow existing standards forinteracting with an STS, such as the WS-Trust protocol. From 306, method300 proceeds to 308.

At 308, the ST is passed to the backend system 120 to authorize abackend call. Therefore, the security identity of the user 102 ispropagated to the backend system 120. The ST may be bound to the backendsystem 120 because the ST digital signature in the ST covers the targetof the ST. Therefore, the cloud application 112 may not cache the ST anduse the cached ST to access other backend systems. From 308, method 300proceeds to 310.

At 310, the backend system 120 validates the backend call. The backendsystem 120 performs the validation by verifying the ST digital signatureincluded in the ST. If the ST also includes a ST lifetime value, thebackend system 120 can also verify whether the ST lifetime has expiredbased on the ST lifetime value. Upon successful validation, the user 102is logged on to the backend system 120, and the backend call can beprocessed in the context of the user 102. From 310, method 300 proceedsto 312.

At 312, the backend system 120 sends a response to the cloud application112. In some implementations, the response can indicate that the user102 has been validated. In some cases, the response can include data orany other information that is requested by the backend call at 308.After 312, method 300 stops.

In some implementations, the messages described in FIG. 3 can betransmitted over an encrypted channel. This approach may mitigate therisk of network attacks such as a replay attack and sniffing (or similarman-in-the-middle attacks) and/or other network attacks.

FIG. 4 is a block diagram 400 of an exemplary computer used in thesecure identity propagation process according to an implementation. Theillustrated computer 402 is intended to encompass any computing devicesuch as a server, desktop computer, laptop/notebook computer, wirelessdata port, smart phone, personal data assistant (PDA), tablet computingdevice, one or more processors within these devices, or any othersuitable processing device, including both physical and/or virtualinstances of the computing device. Additionally, the computer 402 maycomprise a computer that includes an input device, such as a keypad,keyboard, touch screen, or other device that can accept userinformation, and an output device that conveys information associatedwith the operation of the computer 402, including digital data, visualand/or audio information, or a GUI.

The computer 402 can serve as a client (e.g., the user 102), networkcomponent, a server, a database or other persistency, and/or any othercomponent of the secure identity propagation system 100. The illustratedcomputer 402 is communicably coupled with a network 430 (e.g., thenetwork 130). In some implementations, one or more components of thecomputer 402 may be configured to operate within a cloud-computing-basedenvironment.

At a high level, the computer 402 is an electronic computing deviceoperable to receive, transmit, process, store, or manage data andinformation associated with the secure identity propagation system 100.According to some implementations, the computer 402 may also include orbe communicably coupled with an application server, e-mail server, webserver, caching server, streaming data server, business intelligence(BI) server, and/or other server.

The computer 402 can receive requests over network 430 from a clientapplication (e.g., executing on another computer 402) and respond to thereceived requests by processing the said requests in an appropriatesoftware application. In addition, requests may also be sent to thecomputer 402 from internal users (e.g., from a command console or byanother appropriate access method), external or third parties, otherautomated applications, as well as any other appropriate entities,individuals, systems, or computers.

Each of the components of the computer 402 can communicate using asystem bus 403. In some implementations, any and/or all the componentsof the computer 402, both hardware and/or software, may interface witheach other and/or the interface 404 over the system bus 403 using anapplication programming interface (API) 412 and/or a service layer 413.The API 412 may include specifications for routines, data structures,and object classes. The API 412 may be either computerlanguage-independent or -dependent and refer to a complete interface, asingle function, or even a set of APIs. The service layer 413 providessoftware services to the computer 402 and/or the secure identitypropagation system 100. The functionality of the computer 402 may beaccessible for all service consumers using this service layer. Softwareservices, such as those provided by the service layer 413, providereusable, defined business functionalities through a defined interface.For example, the interface may be software written in JAVA, C++, orother suitable language providing data in extensible markup language(XML) format or other suitable format. While illustrated as anintegrated component of the computer 402, alternative implementationsmay illustrate the API 412 and/or the service layer 413 as stand-alonecomponents in relation to other components of the computer 402 and/orsecure identity propagation system 100. Moreover, any or all parts ofthe API 412 and/or the service layer 413 may be implemented as child orsub-modules of another software module, enterprise application, orhardware module without departing from the scope of this disclosure.

The computer 402 includes an interface 404. Although illustrated as asingle interface 404 in FIG. 4, two or more interfaces 404 may be usedaccording to particular needs, desires, or particular implementations ofthe computer 402 and/or secure identity propagation system 100. Theinterface 404 is used by the computer 402 for communicating with othersystems in a distributed environment—including within the secureidentity propagation system 100—connected to the network 430 (whetherillustrated or not). Generally, the interface 404 comprises logicencoded in software and/or hardware in a suitable combination andoperable to communicate with the network 430. More specifically, theinterface 404 may comprise software supporting one or more communicationprotocols associated with communications such that the network 430 orinterface's hardware is operable to communicate physical signals withinand outside of the illustrated secure identity propagation system 100.

The computer 402 includes a processor 405. Although illustrated as asingle processor 405 in FIG. 4, two or more processors may be usedaccording to particular needs, desires, or particular implementations ofthe computer 402 and/or the secure identity propagation system 100.Generally, the processor 405 executes instructions and manipulates datato perform the operations of the computer 402. Specifically, theprocessor 405 executes the functionality required for secure identitypropagation in a cloud-based computing environment.

The computer 402 also includes a memory 406 that holds data for thecomputer 402 and/or other components of the secure identity propagationsystem 100. Although illustrated as a single memory 406 in FIG. 4, twoor more memories may be used according to particular needs, desires, orparticular implementations of the computer 402 and/or the secureidentity propagation system 100. While memory 406 is illustrated as anintegral component of the computer 402, in alternative implementations,memory 406 can be external to the computer 402 and/or the secureidentity propagation system 100.

The application 407 is an algorithmic software engine providingfunctionality according to particular needs, desires, or particularimplementations of the computer 402 and/or the secure identitypropagation system 100, particularly with respect to functionalityrequired for secure identity propagation in a cloud-based computingenvironment. For example, application 407 can serve as one or morecomponents/applications described in FIGS. 1-6. Further, althoughillustrated as a single application 407, the application 407 may beimplemented as multiple applications 407 on the computer 402. Inaddition, although illustrated as integral to the computer 402, inalternative implementations, the application 407 can be external to thecomputer 402 and/or the secure identity propagation system 100.

There may be any number of computers 402 associated with, or externalto, the secure identity propagation system 100 and communicating overnetwork 430. Further, the term “client,” “user,” and other appropriateterminology may be used interchangeably as appropriate without departingfrom the scope of this disclosure. Moreover, this disclosurecontemplates that many users may use one computer 402, or that one usermay use multiple computers 402.

Implementations of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, in tangibly embodied computer software or firmware, incomputer hardware, including the structures disclosed in thisspecification and their structural equivalents, or in combinations ofone or more of them. Implementations of the subject matter described inthis specification can be implemented as one or more computer programs,i.e., one or more modules of computer program instructions encoded on atangible, non-transitory computer storage medium for execution by, or tocontrol the operation of, data processing apparatus. Alternatively or inaddition, the program instructions can be encoded on an artificiallygenerated propagated signal, e.g., a machine-generated electrical,optical, or electromagnetic signal that is generated to encodeinformation for transmission to suitable receiver apparatus forexecution by a data processing apparatus. The computer storage mediumcan be a machine-readable storage device, a machine-readable storagesubstrate, a random or serial access memory device, or a combination ofone or more of them.

The term “data processing apparatus,” “computer,” or “electroniccomputer device” (or equivalent as understood by one of ordinary skillin the art) refers to data processing hardware and encompasses all kindsof apparatus, devices, and machines for processing data, including byway of example, a programmable processor, a computer, or multipleprocessors or computers. The apparatus can also be or further includespecial purpose logic circuitry, e.g., a central processing unit (CPU),an FPGA (field programmable gate array), or an ASIC(application-specific integrated circuit). In some implementations, thedata processing apparatus and/or special purpose logic circuitry may behardware-based and/or software-based. The apparatus can optionallyinclude code that creates an execution environment for computerprograms, e.g., code that constitutes processor firmware, a protocolstack, a database management system, an operating system, or acombination of one or more of them. The present disclosure contemplatesthe use of data processing apparatuses with or without conventionaloperating systems, for example LINUX, UNIX, WINDOWS, MAC OS, ANDROID,IOS, or any other suitable conventional operating system.

A computer program, which may also be referred to or described as aprogram, software, a software application, a module, a software module,a script, or code, can be written in any form of programming language,including compiled or interpreted languages, or declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment. A computer program may, butneed not, correspond to a file in a file system. A program can be storedin a portion of a file that holds other programs or data, e.g., one ormore scripts stored in a markup language document, in a single filededicated to the program in question, or in multiple coordinated files,e.g., files that store one or more modules, sub-programs, or portions ofcode. A computer program can be deployed to be executed on one computeror on multiple computers that are located at one site or distributedacross multiple sites and interconnected by a communication network.While portions of the programs illustrated in the various figures areshown as individual modules that implement the various features andfunctionality through various objects, methods, or other processes, theprograms may instead include a number of sub-modules, third-partyservices, components, libraries, and such, as appropriate. Conversely,the features and functionality of various components can be combinedinto single components as appropriate.

The processes and logic flows described in this specification can beperformed by one or more programmable computers executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., a CPU, an FPGA, or an ASIC.

Computers suitable for the execution of a computer program can be basedon general or special purpose microprocessors, both, or any other kindof CPU. Generally, a CPU will receive instructions and data from aread-only memory (ROM) or a random access memory (RAM) or both. Theessential elements of a computer are a CPU for performing or executinginstructions and one or more memory devices for storing instructions anddata. Generally, a computer will also include, or be operatively coupledto, receive data from or transfer data to, or both, one or more massstorage devices for storing data, e.g., magnetic disks, magneto-opticaldisks, or optical disks. However, a computer need not have such devices.Moreover, a computer can be embedded in another device, e.g., a mobiletelephone, a personal digital assistant (PDA), a mobile audio or videoplayer, a game console, a global positioning system (GPS) receiver, or aportable storage device, e.g., a universal serial bus (USB) flash drive,to name just a few.

Computer-readable media (transitory or non-transitory, as appropriate)suitable for storing computer program instructions and data include allforms of non-volatile memory, media, and memory devices, including byway of example, semiconductor memory devices, e.g., erasableprogrammable read-only memory (EPROM), electrically erasableprogrammable read-only memory (EEPROM), and flash memory devices;magnetic disks, e.g., internal hard disks or removable disks;magneto-optical disks; and CD-ROM, DVD+/−R, DVD-RAM, and DVD-ROM disks.The memory may store various objects or data, including caches, classes,frameworks, applications, backup data, jobs, web pages, web pagetemplates, database tables, repositories storing business and/or dynamicinformation, and any other appropriate information including anyparameters, variables, algorithms, instructions, rules, constraints, orreferences thereto. Additionally, the memory may include any otherappropriate data, such as logs, policies, security or access data,reporting files, as well as others. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, implementations of the subjectmatter described in this specification can be implemented on a computerhaving a display device, e.g., a CRT (cathode ray tube), LCD (liquidcrystal display), LED (Light Emitting Diode), or plasma monitor, fordisplaying information to the user, and a keyboard and a pointingdevice, e.g., a mouse, trackball, or trackpad, by which the user canprovide input to the computer. Input may also be provided to thecomputer using a touchscreen, such as a tablet computer surface withpressure sensitivity, a multi-touch screen using capacitive or electricsensing, or other type of touchscreen. Other kinds of devices can beused to provide for interaction with a user as well; for example,feedback provided to the user can be any form of sensory feedback, e.g.,visual feedback, auditory feedback, or tactile feedback; and input fromthe user can be received in any form, including acoustic, speech, ortactile input. In addition, a computer can interact with a user bysending documents to and receiving documents from a device that is usedby the user; for example, by sending web pages to a web browser on auser's client device in response to requests received from the webbrowser.

The term “graphical user interface,” or “GUI,” may be used in thesingular or the plural to describe one or more graphical user interfacesand each of the displays of a particular graphical user interface.Therefore, a GUI may represent any graphical user interface, includingbut not limited to, a web browser, a touch screen, or a command lineinterface (CLI) that processes information and efficiently presents theinformation results to the user. In general, a GUI may include aplurality of user interface (UI) elements, some or all associated with aweb browser, such as interactive fields, pull-down lists, and buttonsoperable by the business suite user. These and other UI elements may berelated to or represent the functions of the web browser.

Implementations of the subject matter described in this specificationcan be implemented in a computing system that includes a back-endcomponent, e.g., as a data server, or that includes a middlewarecomponent, e.g., an application server, or that includes a front-endcomponent, e.g., a client computer having a graphical user interface ora web browser through which a user can interact with an implementationof the subject matter described in this specification, or anycombination of one or more such back-end, middleware, or front-endcomponents. The components of the system can be interconnected by anyform or medium of wireline and/or wireless digital data communication,e.g., a communication network. Examples of communication networksinclude a local area network (LAN), a radio access network (RAN), ametropolitan area network (MAN), a wide area network (WAN), WorldwideInteroperability for Microwave Access (WIMAX), a wireless local areanetwork (WLAN) using, for example, 802.11 a/b/g/n and/or 802.20, all ora portion of the Internet, and/or any other communication system orsystems at one or more locations. The network may communicate with, forexample, Internet Protocol (IP) packets, Frame Relay frames,Asynchronous Transfer Mode (ATM) cells, voice, video, data, and/or othersuitable information between network addresses.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

In some implementations, any or all of the components of the computingsystem, both hardware and/or software, may interface with each otherand/or the interface using an application programming interface (API)and/or a service layer. The API may include specifications for routines,data structures, and object classes. The API may be either computerlanguage-independent or -dependent and refer to a complete interface, asingle function, or even a set of APIs. The service layer providessoftware services to the computing system. The functionality of thevarious components of the computing system may be accessible for allservice consumers via this service layer. Software services providereusable, defined business functionalities through a defined interface.For example, the interface may be software written in JAVA, C++, orother suitable language providing data in extensible markup language(XML) format or other suitable format. The API and/or service layer maybe an integral and/or a stand-alone component in relation to othercomponents of the computing system. Moreover, any or all parts of theservice layer may be implemented as child or sub-modules of anothersoftware module, enterprise application, or hardware module withoutdeparting from the scope of this disclosure.

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of anyinvention or on the scope of what may be claimed, but rather asdescriptions of features that may be specific to particularimplementations of particular inventions. Certain features that aredescribed in this specification in the context of separateimplementations can also be implemented in combination in a singleimplementation. Conversely, various features that are described in thecontext of a single implementation can also be implemented in multipleimplementations separately or in any suitable sub-combination. Moreover,although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to asub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation and/or integration ofvarious system modules and components in the implementations describedabove should not be understood as requiring such separation and/orintegration in all implementations, and it should be understood that thedescribed program components and systems can generally be integratedtogether in a single software product or packaged into multiple softwareproducts.

Particular implementations of the subject matter have been described.Other implementations, alterations, and permutations of the describedimplementations are within the scope of the following claims as will beapparent to those skilled in the art. For example, the actions recitedin the claims can be performed in a different order and still achievedesirable results.

Accordingly, the above description of example implementations does notdefine or constrain this disclosure. Other changes, substitutions, andalterations are also possible without departing from the spirit andscope of this disclosure.

What is claimed is:
 1. A method, comprising: receiving, from a user, afirst security response message; transmitting, to the user in responseto receiving the first security response message, a second securityresponse message, wherein the second security response message comprisesa Token Granting Token (TGT); receiving, from a cloud application, aService Token (ST) request, wherein the ST request comprises the TGT;verifying the ST request based on the TGT; generating, in response tothe verifying, a ST, wherein the ST is used to validate an accessrequest to access a backend system; and transmitting the ST to the cloudapplication.
 2. The method of claim 1, wherein the first securityresponse message is generated by an Identity Provider (IDP).
 3. Themethod of claim 1, wherein the TGT comprises a TGT digital signature,and wherein the verification of the ST request is based on the TGTdigital signature.
 4. The method of claim 3, wherein the TGT furthercomprises a lifetime parameter, and wherein the verification is furtherbased on the lifetime parameter.
 5. The method of claim 1, wherein theST comprises a ST digital signature that is used in validating theaccess request.
 6. The method of claim 5, wherein the ST furthercomprises a lifetime parameter, and wherein the lifetime parameter isused in the validation.
 7. The method of claim 1, wherein the secondsecurity response message is transmitted from a cloud platform thathosts the cloud application.
 8. The method of claim 1, wherein the firstand the second security response messages are formatted according to aSecurity Assertion Markup Language (SAML) specification.
 9. A system,comprising: a memory; at least one hardware processor interoperablycoupled with the memory and configured to: receive, from a user, a firstsecurity response message; transmit, to the user in response toreceiving the first security response message, a second securityresponse message, wherein the second security response message comprisesa Token Granting Token (TGT); receive, from a cloud application, aService Token (ST) request, wherein the ST request comprises the TGT;verify the ST request based on the TGT; generate, in response to theverifying, a ST, wherein the ST is used to validate an access request toaccess a backend system; and transmit the ST to the cloud application.10. The system of claim 9, wherein the first security response messageis generated by an Identity Provider (IDP).
 11. The system of claim 9,wherein the TGT comprises a TGT digital signature, and wherein theverification of the ST request is based on the TGT digital signature.12. The system of claim 11, wherein the TGT further comprises a lifetimeparameter, and wherein the verification is further based on the lifetimeparameter.
 13. The system of claim 9, wherein the ST comprises a STdigital signature that is used in validating the access request.
 14. Thesystem of claim 13, wherein the ST further comprises a lifetimeparameter, and wherein the lifetime parameter is used in the validation.15. The system of claim 9, wherein the second security response messageis transmitted from a cloud platform that hosts the cloud application.16. The system of claim 9, wherein the first and the second securityresponse messages are formatted according to a Security Assertion MarkupLanguage (SAML) specification.
 17. A non-transitory, computer-readablemedium storing computer-readable instructions for secure identitypropagation, the instructions executable by a computer and configuredto: receive, from a user, a first security response message; transmit,to the user in response to receiving the first security responsemessage, a second security response message, wherein the second securityresponse message comprises a Token Granting Token (TGT); receive, from acloud application, a Service Token (ST) request, wherein the ST requestcomprises the TGT; verify the ST request based on the TGT; generate, inresponse to the verifying, a ST, wherein the ST is used to validate anaccess request to access a backend system; and transmit the ST to thecloud application.
 18. The medium of claim 17, wherein the firstsecurity response message is generated by an Identity Provider (IDP).19. The medium of claim 17, wherein the TGT comprises a TGT digitalsignature, and wherein the verification of the ST request is based onthe TGT digital signature.
 20. The medium of claim 19, wherein the TGTfurther comprises a lifetime parameter, and wherein the verification isfurther based on the lifetime parameter.